1. The Field of the Invention
The present invention generally relates to Web service policies in a distributed system. More particularly, the present invention provides for a policy processing model for determining if messages associated with an application satisfy web service policy assertions.
2. Background and Related Art
Computerized systems provide many advantages towards people's ability to perform tasks. To enable these advantages, computer systems often come equipped with (or are expandable to include) multiple hardware devices that can store or read data or enable a software program to perform a specific action on data. Such devices can include, e.g., a hard drive, a Compact Disk (i.e., CDROM, CDRW, ect.), a Universal Serial Bus (USB) devise (e.g., a printer, a scanner, etc.), and so on. Present computer systems also commonly have installed there on multiple software (or “applications”) programs such as a word processing program, a spread sheet program, an imaging program, and an electronic mail program, which instruct the devices to perform specific actions on the data.
Businesses rely heavily on such computerized systems to manage and store information, which is the life blood of most businesses. From a customer relations management suite, or a payroll application to a manufacturing system, businesses increasingly rely on such computerized technology to make better use of various types of information they depend on everyday. These systems typically “built to task, and built to last” perform well in isolation, accomplishing the specified task they were designed for. But true value comes from connecting systems together. For example, say you have a stand alone inventory system. If you don't connect it to anything else, it is not as valuable as it could be. The system can track inventory, but not much more. Inventory information may have to be entered separately in the accounting and costumer relation management systems. The inventory system may be unable to automatically place orders to suppliers. Accordingly, the benefits of such inventory system are diminished by high over head costs.
If, however, you were able to connect your inventory system to your accounting system, such connection has the potential for getting more interesting. Now, whenever you buy or sell something, you potentially have the possibility of your inventory and your cash flow being tracked in one step. If you go further, and connect your warehouse management system, custom ordering systems, supplier ordering systems, and your shipping company, suddenly that inventory management system could be worth a lot more. You could then do end-to-end management of your business while dealing with each transaction only once, instead of once for every system it affects. A lot less work and a lot less opportunity for errors.
Until recently, however, custom integration was thought to be expensive, time-consuming and brittle. For example, because the sales data base and the accounting system are typically not designed to work with each other (i.e., because the data for each application is formatted and accessed according to the way the application program was formatted), connecting the two can be expensive and time-consuming. Accordingly, the potential benefits can be out weighed by such expense and time. Further, even if the systems were able to be integrated, making changes to either or possibly adding other systems could break the link, thereby causing more time and more money.
Web services, however, are turning the way we build and use software inside out. Web services let applications share data, and—more powerfully—invoke capabilities from other applications without regard to how those applications were built, what operating system or platform they run on, and what devices are used to access them. Although Web services remain independent of each other, they can loosely link themselves into a collaborating group that forms a particular task. Web services are invoked over the internet by means of industry-standard protocols including SOAP (Simple Object Access Protocol), eXtensible Markup Language (XML), and Universal Description, Discovery and Integration (UDDI), Web Service Description Language (WSDL), etc.
A key benefit of the emerging Web services architecture is the ability to deliver intergraded, interoperable solutions. Because, however, Web services provide various services from different businesses, organizations, and other service providers via the Internet, security issues are a main concern to protect the information that is transferred. Accordingly, Web service protocols have established security standards that describe enhancements to messaging protocols (e.g., SOAP messaging) to provide quality of protection through message integrity, message confidentiality, and single message authentication.
For instance, there are mechanisms that can be used to accommodate a wide variety of security models and encryption technologies. Some Web service security protocols provide a general-purpose mechanism for associating security tokens with messages. Other Web service securities describe how to encode binary security tokens. Specifically, one specification describes how to encode x509 certificates and Kerberos tickets as well as how to include opaque encrypted keys. This particular service also includes extensibility mechanisms that can be used to further describe the characteristics of the credentials that are included within a message.
By themselves, Web service securities do not ensure security nor do they provide a complete security solution. Web service securities are building blocks that are used in conjunction with other Web services and application-specific protocols to accommodate a wide verity of security models and encryption technologies. For example, Web service securities are used in conjunction with Web service policies, which provide a flexible and extensible grammar for expressing capabilities, requirements, and general characteristics of entities in a Web service-based system.
Web service policies define a framework and a model for the expression of these properties as policies. Policy expressions allow for both simple and declarative assertions as well as more sophisticated conditional assertions. Further, some assertions specify traditional requirements and capabilities that will ultimately manifest on the wire (e.g., authentications scheme, transport protocol selection). Other assertions specify requirements and capabilities that have no wire manifestation yet are critical to proper service selection and usage (e.g., privacy policy, Quality of Service (QoS) characteristics). Nevertheless, Web service policies provide a single policy grammar to allow both kinds of assertions to be reasoned about in a constant manner.
In order to take advantage of the policy and security availabilities provided through Web services, application developers must typically write code within the application itself to access and implement these policy and security features. In addition, they must generate code to determine what policies, if any, apply to a particular type of message, associated with a particular application and destined for an endpoint. Having to create such code in an application, however, has several draw backs. For example, once compiled the defined policies become unchangeable within that particular application, and a new version of the application must be created if changes are desired. Further, if the specified policy and/or security features specified in the application are no longer supported, the application cannot be extended to support alternative updates—unless, of course, an updated version of the application is created. As such, there is neither flexibility nor ease in extending the system. Further, because such application developers are typically not experts in such policy issues, there are security concerns that come into play, as well as performance, stress and/or other robustness factors.
Accordingly, there exists a need for allowing a developer to declaratively state the desired policies in a flexible, extensible and robust manner.